Method and system for firewall friendly real-time communication

ABSTRACT

Method and system for transmitting packets of different data types from a sender client to a receiver client over a server client connection established in a packet switched network, where a transport protocol connection for each data type to be transmitted is established between the sender client and the receiver client using the server client, the data transfer rate of one or more data type connections are measured at the server client, which transfer rate is sent as feedback information to the sender client, the sending rate at the sender client is adapted based on the feedback information from the server client and the transfer rate measured by the sender client, data types are prioritized in priority and non-priority delay sensitive data types by marking the data packets, non-priority data type packets are dropped at the sender client if the transport connections dedicated for non-priority data are too busy to send more data, the individual data types are separately buffered at the server, non-priority data type packets are dropped at the server before they are buffered if a corresponding dedicated data type buffer with a size of N packets is full until the buffer contains a number of M packets, where M&lt;N.

The present invention relates to transmission of information acrossnetworks, more specifically to methods and systems for fast real-timetransmission of information across the Internet and within networks ornetworked systems.

Network based applications like conferencing or collaboration systems,which share local data and applications and provide real-time audio andvideo communication, require real-time transmission and exchange of datafor effective implementation and use of those features. There existseveral protocol suites that provides fast, real time data exchange topresent video and audio data between users in local and remotelocations. Typically, real-time data is transmitted over the unreliableUser Datagram Protocol UDP (UDP/IP). The advantage of using theunreliable UDP protocol instead of the reliable Transmission ControlProtocol TCP (TCP/IP) is primarily an increased speed of packet deliveryfor the real-time applications that does not require reliable datatransmission. This is possible because UDP has less overhead and doesnot transmit packet acknowledgement, packet verification, packetre-transmission requests, etc. In real-time media transmission, suchtransmissions and verification processes negatively impact the systemperformance regarding fast packet delivery.

The TCP protocol is the dominant transport layer protocol for networkcommunication and the TCP protocol provides the highest degree ofreliability by ensuring that all data is received and that it isreceived in the correct order, as well as the received data is accurateand consistent with the data that was transmitted. In many applications,such a reliability is crucial for effective and useful datatransmission.

It would be desirable if real-time data could be carried over TCPconnections because TCP connections are widely accepted by mostfire-walls, since this type of connection is used for other purposessuch as web browsing. TCP transmission ports are known to be friendlierto network security than UDP ports, which in general are seen assecurity threat. In businesses such as bank and finance, security is ofhighest priority, and communications via UDP ports must be avoided.

However, it is well recognized that the TCP protocol is not of practicaluse for communication of real-time transmission such as voice and videodata. This is due to the fact that TCP connections will often introducesignificant delays and throughput variations in the delivery of data,because of the changes in the network load and the reliable nature ofthe protocol. The design goal of TCP has been to provide a reliablenetwork connection as opposed to real-time and constant-flow networkconnections using the UDP protocol. Accordingly, the throughput of atypical TCP connection varies according to the network packet-deliveringsituation.

The dilemma is that if UDP is used to provide real-time communication,the UDP connections are very likely to be blocked by firewalls. However,if TCP is used, the result is stuttering of the data, which isunacceptable for video and in particular for audio communication. Thestuttering occur in case of a data packet loss, where the TCP receiverwill wait and hold all the following packets until the lost packet isresent and received. When the lost packet is resent and arrives, all theheld packets are delivered to the application at once. This causes thewell-known stall-and-fast-forward symptom when using TCP as transportprotocol. Most operating systems are implementing the TCP protocol withindividual send and receive buffer sizes for each connection, which isalso called socket buffer sizes. These buffers implies that applicationssending data to a TCP connection will experience the data as sent whenis reaches the send buffer, which will cause problems for real-timetransmission, since packets with useful data are delayed.

US Patent Application 2006/0198300 (Li et al.) describes a method forusing the TCP-protocol for real-time communication such as video andaudio transmission. The method disclosed in said application teachesthat the problems using TCP for real-time communication can be solved byopening a plurality of TCP connections and by choosing the leastcongested connection for the transmission of each packet of data. Theselection of connection is done by monitoring the plurality of TCPconnections and by determining the queue of data to be sent over eachindividual connection.

This method does not adapt the transmission rate of packets to theavailable capacity of the network, and thus assumes that at least one ofthe connections is ready to transport data. Hence it does not solve theproblems that caused the congestion, and does not teach how severalconnections of different data types are transmitted simultaneously.

US Patent Application 2002/0085587 discloses a method for end-to-endbandwidth estimation between a server and a client in a packet networksuch as IP, which method is used to regulate the data rate at the clientside to improve the throughput of the transport protocol. The method canbe used with any transport protocol and solves the problem of lackingfairness to TCP connections when they compete with UDP connections on acommunication link. The method estimates the available bandwidth bymeasuring the received amount of data between two acknowledgements,which is somewhat similar to standard proposal RFC3448. The applicationdescribes the method to be used in connection with a transport protocol,but the application does not teach or point towards the use of themethod in connection with the TCP protocol, since the fairness problemlies at the UDP protocol or similar protocols, which does not havecongestion control mechanisms.

The congestion problem is described in the standard proposal TCPFriendly Rate Control (TRFC) described in RFC3448, which discloses analgorithm to make a reasonably fair allocation of bandwidth between TCPand UDP connections, which exists on the same link. The standardproposal describes the principle of measuring available bandwidth at thereceiver side and sending feedback information from the receiver to thesender. TRFC is intended to be used in conjunction with a transportprotocol such as UDP to improve fairness to TCP connections, but againnothing indicates that the principles should be used with TCP. Thegeneral considerations on congestion problems described in the standardproposal, gives the impression that use of large data packets could leadto a higher throughput for TCP as transport protocol.

The standard proposal RFC3714 discusses QoS and congestion regardingVoIP over the Internet in several aspects and teaches that networklimitations in general lie in the transfer rate in bits per second Bpsrather than the transfer rate in packets per second pps. But thestandard proposal also states the same issue as mentioned above that themechanisms found in TCP provide an incentive to use large data packetsto obtain a larger throughput.

On the background outlined above it is the general object of theinvention to provide a method and a system for real-time communicationacross networks using a firewall friendly protocol, where theshort-comings and disadvantages described above are overcome.

To achieve these and other objects, as will become apparent from thefollowing description, there is provided, according to a first aspect ofthe invention a method for transmitting packets of different data typesfrom a sender client to a receiver client over a server clientconnection established in a packet switched network, where

-   -   a transport protocol connection for each data type to be        transmitted is established between the sender client and the        receiver client using the server client,    -   the data transfer rate of one or more data type connections are        measured at the server client, which transfer rate is sent as        feedback information to the sender client,    -   the sending rate at the sender client is adapted based on the        feedback information from the server client and the transfer        rate measured by the sender client,    -   data types are prioritized in priority and non-priority delay        sensitive data types by marking the data packets,    -   non-priority data type packets are dropped at the sender client        if the transport connection dedicated for non-priority data is        too busy to send more data,    -   the individual data types are separately buffered at the server,    -   non-priority data type packets are dropped at the server before        they are buffered if a dedicated data type buffer with a size of        N packets is full until the buffer contains a number of M        packets, where M<N.

By using this method the inventors has realized that the disadvantagesthat occurs when some transport protocols are used for real-timetransmission can be reduced significantly, since the method minimizesthe delay and congestion induced by packets that are buffered andretransmitted. This is achieved because the data transfer rates aremeasured at the sender client and the receiver client, and moreimportant the server client sends the measured transfer rate as feedbackinformation to the sender client. By using this feedback information toadjust the transfer rate at the sender client, congestion is reducedbecause the sending transfer rates are adapted to the availablecapacity. Because the data types are prioritized, packets that aresusceptible to delays can be dropped or allocated more bandwidth andpriority data type packets can be buffered in case the networkconnections are too busy to send more data or suffers from congestion.Data that cannot be sent right away, and which will suffer under delayswill be dropped and therefore categorized as non-priority data, sincethe delivery of all packets are not crucial. This is due to the factthat for some data types packets are better of being dropped rather thandelivered with a large delay.

To avoid oscillation of the buffer size at the server client in case ofcongestion and a delay of several packets and to achieve a smootherpacket delivery, the server client will drop non-priority packets untilthe buffer or buffers dedicated for non-priority data type reaches alimit M, if the buffer reaches a upper limit N. This has shown to beespecially effective when a non-priority buffer has a size N of 4packets and a limit M of 2 packets.

In another embodiment of the invention the non-priority data typepackets are dropped at the receiver client if a predetermined bufferwith a size of P packets is full.

The process of dropping packets at the receiver does not give anyfeedback to the sender and will not influence the transfer rate of thesender. When network congestion happens, packets are sent withsignificant delays compared to the normal interval between e.g. twoaudio samples and by having a buffer of a limited size and droppingpackets when it is full, delays will not be propagated if severalpackets are received at once after a period with congestion. By droppingnon-priority packets at the receiver delays affecting the use of thereceived useful data is reduced.

In an embodiment of the invention the buffer P at the receiver has asize of 3 packets, which has shown to be especially efficient forpreventing delays in real-time data transmission.

In a further embodiment of the invention connection send buffers at thesender client and at the server client are decreased in size orpreferably disabled. This minimizes further delays because thenotification of a sent packet is then received when the packet isactually sent on the connection and not as usually, when the packet isreceived in the connection send buffer. Hereby the management of bufferswith data to send is handled at the client application level, whichgives the client application more precise information about when thedata packets actually are sent.

In an embodiment of the invention the method has shown to be especiallyuseful regarding audio data and video data that will suffer from delays,as non-priority data with respect to the delivery of all data packets.

In another embodiment of the invention the transfer rate for eachconnection at the server client is calculated by measuring the number ofreceived packets in T successive time intervals of duration D and wherepackets dropped by the server is not taken into account when thetransfer rate is calculated. This approach is very simple to implementand provides useful information for adapting the transfer rate at thesender client. By not taking dropped packets into account, this willcause the sender client to lower its sending data rate, and therebylimiting the possibility for congestion and latency on the connections.

In another embodiment of the invention the transfer rate of non-prioritydata type connections are adapted at the sender client by limiting thetransfer rate of another non-priority data type connection or a prioritydata type connection. This makes sure that data, which is regarded asnon-priority with respects to delivery of all packets, are favoured interms of bandwidth in order to reduce packet delay and congestion.

In another embodiment of invention the data type transfer rates at thesender client is adapted by changing the video or audio sampling rate.This especially be useful when dealing with low capacity connections tomake sure that the connections are not congested and that delaysensitive packets are buffered, but useful data still can betransmitted.

In another embodiment of the invention the same result is achieved byadapting the transfer rate of the data connections at the connectionlevel by blocking the connections for specified time intervals.

In another embodiment the transmitted packet sizes correspond to thenetwork MTU (maximum transmission unit). This reduces the impact ofdropping non-priority packets, when a buffer is full or a connection istoo busy to send more data. Normally when running other bandwidthconsuming streams such as video and shared applications on the same linkas e.g. audio data, the bandwidth consuming streams will normally sendlarger packets and get a higher transfer priority compared to the smallpackets of a audio stream that will be delayed. To prevent this tohappen small packet sizes, which corresponds to the network MTU are usedfor all connections. This has shown to improve the both the overalltransfer rate and the number of lost and dropped packets. This stemsfrom the fact that if packets are larger than the network MTU, they arefragmented during transmission and all fragments of a packet must arriveat high-level protocol to get the packet. Therefore if any fragment of apacket is dropped, the entire packet must be retransmitted. The effektof sending small packets is that the packets are not delayed due tofragmenting and retransmission of lost fragments.

In another embodiment of the invention the transport protocol is thetransmission control protocol TCP, which makes it possible tocommunicate using existing firewall ports. This makes a systemimplementing the method of transmission described in the invention moresecure than existing alternatives and makes real-time data transmissionin environments where a high security level is required, possible.

In order to achieve the advantages of sending small packets the Naglealgorithm in the TCP protocol is disabled. This makes sure that a hightransfer rate of small packets is favoured.

For the implementation of the transmission method and the advantagesthereof described above there is provided, according to a further aspectof the invention, a system for transmitting packets of different datatypes from a sender client to a receiver client over a server clientconnection established in a packet switched network, where

-   -   a transport protocol connection for each data type to be        transmitted is established between the sender client and the        receiver client using the server client,    -   the data transfer rate of one or more data type connections are        measured at the server client, which transfer rate is sent as        feedback information to the sender client,    -   the sending rate at the sender client is adapted based on the        feedback information from the server client and the transfer        rate measured by the sender client,    -   data types are prioritized in priority and non-priority delay        sensitive data types by marking the data packets,    -   non-priority data type packets are dropped at the sender client        if the transport connections dedicated for non-priority data are        too busy to send more data,    -   the individual data types are separately buffered at the server,    -   non-priority data type packets are dropped at the server before        they are buffered if a corresponding dedicated data type buffer        with a size of N packets is full until the buffer contains a        number of M packets, where M<N.

In another embodiment of this aspect of the invention the non-prioritydata type packets are dropped at the receiver client if a predeterminedbuffer with a size of P packets is full.

In another embodiment of the invention connection send buffers at thesender client and at the server client are decreased in size orpreferably disabled.

In another embodiment of the invention the non-priority data comprisesaudio data and/or video data.

In another embodiment of the invention the transfer rate at the serverclient is calculated by measuring the number of received packets in Tsuccessive time intervals of duration D and where packets dropped by theserver is not taken into account when the transfer rate is calculated.

In another embodiment of the invention the transfer rate of non-prioritydata type connections are adapted at the sender client by limiting thetransfer rate of another non-priority data type connection or a prioritydata type connection.

In another embodiment of the invention the data type transfer rates atthe sender client are adapted by changing the video or audio samplingrate.

In another embodiment of the invention the transfer rate of the dataconnections is adapted at the connection level by blocking theconnection for specified time intervals.

In another embodiment of the invention the buffer P has a size of 3packets.

In another embodiment of the invention the buffer size for non-prioritydata at the server client is N=4 with M=2.

In another embodiment of the invention the transmitted packet sizescorresponds to the network MTU.

In another embodiment of the invention the transport protocol is thetransmission control protocol TCP.

In another embodiment of the invention the Nagle algorithm is disabled.

In the following the invention will be further explained by way of apreferred embodiment as illustrated in the drawings, on which

FIG. 1 illustrates a system implementing the method of the invention,

FIG. 2 is a block diagram of the handling of packets at a sender client,

FIG. 3 is a block diagram showing how the transfer rate is measured andadapted at a sender client,

FIG. 4 is a block diagram showing how packets are buffered and droppedat a server,

FIG. 5 is a block diagram showing how packets are buffered and droppedat a receiver client.

FIG. 1 shows a preferred embodiment where the method according to theinvention is implemented in a system that provides individualconnections for secure conference communication of data types comprisingaudio, video, application sharing and generic file transfer data, whichconnections all are created by default when the conference is created.For each individual data type connection there are two connections, onefor sending and one for receiving. The connections are featurespecialized and are dedicated for each their communication features asmentioned above. In general the individual data types comprise usefuldata. The system is based on a client-server model where a clientapplication at the client computer 1 connects to a server application ata server 2 in order to perform real-time communication with one or moreother clients 1 a, 1 b . . . 1 n in the system. It is obvious to aperson skilled in the art that one of the clients could act as a server(server client) to the other clients and that both clients and serverscan act as both sender and receiver of data. The communication is basedon firewall friendly real-time HTTPS-based streaming, which is carriedby TCP/IP connections, and the security is ensured by exchange of publickeys for encryption 3, hence the clients 1, 1 a, 1 b . . . 1 n do notcommunicate directly with each other but through the server 2. Theserver 2 sends transfer rate feedback information 4 to the clients 1, 1a, 1 b . . . 1 n, which is used to adapt the transfer rates of theindividual connections. The connections use port 80 or 443 and for otheradministrative purposes port 6085 is used.

The clients 1, 1 a, 1 b . . . 1 n are equipped with audio and videocapture equipment for the purpose of video and audio conferencing. Aconference is established when a client e.g. client 1 requests theserver 2 for the creation of a conference. In the same way a client 1, 1a, 1 b . . . 1 n can join a conference and thereby send and receive datafrom one or more of the other clients 1, 1 a, 1 b . . . 1 n. During aconference, data that passes through the server needs to be decryptedand re-encrypted by the server since the client connections usesdifferent SSL sessions.

During a conference, the captured audio samples are packaged in aconnection specific format and sent through the server 2. At thereceiver client the audio packets are extracted and played with an audioAPI corresponding to the one used for capturing the packets. In case ofvideo, the capture frames are packaged and sent through the server,extracted at the receiver client and played with an video APIcorresponding to the one used for capturing the frames.

In the preferred embodiment the invention is used to implement a systemthat is more than just a conferencing system. The invention ispreferably used to implement a collaboration system, where people atdifferent locations can collaborate by sharing data, computerapplications and their personal computer desktops, while having aconference session that provides real-time video and audio streamingbetween the users.

For sharing applications a mirror video driver is used to capture allscreen changes and mouse and keyboard events. The updated screen regionsare received as bitmaps and then archived using LZ compression. Thearchived content is packed in a connection specific format, as well asthe mouse and keyboard inputs, and sent through the server. At thereceiver client the images are unpacked and rendered in the applicationshare window, together with mouse movements. In case of remote control,mouse movements and keyboard events are captured at the receiver end,sent through the server and transformed in the user input at theapplication share sender end.

During a file transfer, data is extracted from a disk file, packaged andsent through the server. The connection expects acknowledgement messagesafter each chunk of data and if no acknowledgements are received after anumber of chunks, the sending is paused. At the receiver end the chunksare saved into a disk file.

During a conference data will be sent in both directions, which ishandled by having connections 6 in both directions, but for the sake ofsimplicity only one side of the communications process is described inthe following.

FIG. 2 illustrates how data packets are handled at the sender client,where packets are marked as priority and non-priority data, with respectto the importance of packet delivery. Hence data types that do notsuffer from one or more packets being dropped, but which will sufferfrom delayed packets are marked as non-priority data. In the preferredembodiment audio and video data is categorized as non-priority data.Packets are sent from the client until a send function implemented inthe TCP connection, reports it is too busy to send more data. In thatcase a OK to send flag is set to FALSE on the individual connection andnon-priority packets are dropped and priority data are buffered untilthe connection signals readiness to sending more packets and the flag isset to TRUE. This principle is shown in FIG. 2 where a marked datapacket in step 201 is ready to be sent and the state of the connectionsis checked in step 202. If the connection is ready to send the clientapplication continues in step 203 where the data packet is sent. If theresult in step 202 is that the connection is too busy to send data theclient application checks the data type of the packet in step 204. Ifthe packet is marked as priority data the data packets are buffered instep 205, but if the packet is marked as non-priority data the datapacket is dropped in step 206. If the connection cannot accept any moredata for direct send, the client application will drop data packetsuntil the connection signals ready to send. Depending on the data natureand the marking of the data packets, the client application can buffer anumber of packets before it starts to drop packets in order to avoiddata starvation the moment the connection is ready to send data. It isobvious that data types can be prioritized differently, depending on thedata nature. Each specific data types can have different buffer sizes orno buffers at all depending on the nature of the data to be transferredand a number of packets can be buffered before the sender client startsto drop packets.

FIG. 3 illustrates how the transfer rate of the individual connectionsbetween a server and a client are adapted. In step 301 the clientapplication sends data to the server on the individual connections andin step 302 the server measures the actual transfer rate to the receiverclient. This transfer rate is fed back to the sender client in step 303,which in step 304 compares the transfer rate measured by the server andthe transfer rate measured by the sender client itself. A counter c isincreased in step 306 if there is a difference between the two transferrates and reset in step 305 if the two transfer rates are equal. Thecounter c counts the number of consecutive times the server reports atransfer rate that differs from the transfer rate at the sender client.In step 307 the client application checks if c is equal to 3, theprocess continues in step 302. If the server in 3 consecutive reports adifference between the two transfer rates (c is equal to 3 in step 307),the transfer rate at the client is adapted in step 308 and c is set to 0in step 305. It should be understood that this is performed on each ofthe individual connections and that the counter c could be set toanother limit for adjusting the transfer rate depending on the networkconditions. Since all connections transfer rates are measured, theinformation about the individual transfer rates can be used to adapt thetransfer rate to the actual demand. The transfer rate of one or more ofthe individual data type connections can be limited in order to increasethe transfer rate of another data type connection. This will ensure thatnon-priority data can be provided with enough bandwidth to minimize thenumber of dropped packets and the delay of delivered packets. Based onthe measurements made by the server on the actual transfer rates and theoverall priority of the different connections, the transfer rate isadapted at the sender client. If for example the application needs X₁bytes/s for the audio transmission and the server reports an effectivetransfer rate of X₂ bytes/s to the receiver client, where X₂<X₁, theapplication will limit the video transfer rate X₃ to X₃−(X₁−X₂), if theserver for 3 consecutive feedbacks to the client reports that X2 issmaller than X1. It is obvious to a person skilled in the art, that thetransfer rates can be adapted in several different ways depending on thecircumstances and demands for the connections and that the transfer ratecan be measured in several ways at different places in the system. Incase the server estimation within a range is the same as the clientestimation of the transfer rate and all connections can transfer attheir current transfer rate for at few consecutive intervals, the clientincreases the transfer rate. It is obvious that said range could bedefined according to the data type connections and the demands for theconference. The transfer rate of the connections can be increased onbasis of the data types and on the demands and the nature of theindividual data types, one connection can be allocated bandwidth beforethe other connections are increased. Typically the increment of thetransfer rate is a percentage of the current transfer rate rate, thatcan be defined form the network conditions or transmission requirementsfor a given conference. It is obvious to a person skilled in the artthat transfer rates can be increased in many other ways.

The limitation of the transfer rates are either performed at thesampling level by for example changing the video frames per second orthe audio sampling rate or by blocking the connections for specifiedtime intervals in order to achieve the desired data rate. When thetransfer rates are adapted the audio data has preference over other datatypes as it cannot go under a pre-defined transfer value of 2.5 kbit/s.This is also the case for application share but in terms of bandwidthits priority comes after audio. The transfer rate of other connectionscan drop to almost 0. The server measures the transfer rate in step 302by measuring the total number of bytes B transferred to the receiverclient during 3 time intervals T of duration D=3 seconds. After Tintervals the maximum value for B is chosen and divided by D to obtainthe transfer rate R in bytes/s. It is obvious to a person skilled in theart that the transfer rate can be measured for other time interval andby using other transfer parameters, but the approach above is chosen inthis embodiment.

FIG. 4 illustrates how non-priority data packets are dropped at theserver depending on the sizes of the buffers dedicated to the individualconnections to avoid oscillation of the buffers. The server constructs abuffer for each data type connection, which can be user defined or atdefault size, depending on the network conditions. When the buffer isfilled with N packets, all incoming non-priority packets are dropped andthe server only stop dropping new packets when the number of bufferedpackets reaches a number of M data packets, where M<N. Packets that aredropped will not be taken into account when calculating the transferrate, as described in FIG. 3. In this way the server dropping packetswill cause the sender to lower its data transfer rate. In step 401 adata packet is transmitted form a client and then received at the serverin step 402. In step 403 the server determines the data type of thepacket and buffers the packet in step 404 if the packet is a prioritypacket and a new packet can be received in step 402. If the packet instep 403 is determined to be a non-priority data packet, the serverchecks the buffer size in step 405. If the buffer size does not equal 4packets the data packet is buffered and a new packet can be received instep 402. If the buffer size is determined to be equal to 4 packets instep 405, the server will start to drop new data packets in step 407,until the buffer size is 2 packets as illustrated in step 408. In theembodiment illustrated above the limits for N and M is set to 4 and2,but other limits can be used as well, but the values used in theexample has shown to work with most network conditions. It is clear thatunder perfect conditions no buffers are needed because the server thencan send the packets immediately and do not require a buffer. It is alsoobvious that the values can be user specified upon the set up of aconnection if the server or the client are aware of certain networkconditions that requires special buffer sizes or if a larger delay ofnon-priority packets can be accepted in a special case.

In the preferred embodiment of the invention the connection send buffersat the clients 1, 1 a, 1 b . . . 1 n and the server 2 are disabled or ifthe specific implementation does not allow this, their sizes are reducedto a minimum. Hereby the notification of a sent packet is received whenthe packet is actually sent on the connection and not as usually, whenthe packet is received in the connection send buffer.

In the preferred embodiment the data packets are transmitted on theconnections in packet sizes equal to and around the size of the networkMTU. As shown in FIG. 1 the invention is preferably implemented with theTCP protocol and to ensure that small packets are not discriminated, theNagle algorithm is disabled both at the server 2 and the clients 1, 1 a,1 b . . . 1 n. The data type packets need not to be fixed or equal insizes and in a preferred implementation the data packets for audio willbe around 110 to 450 bytes, for video up to 2.5 kB, for applicationshare 100 to 1400 bytes, for file transfer 350 bytes to 2 kB and for adata connection usually under 1 kB. Typically the connections arecarried over Ethernet, which typically has an MTU of 1500 bytes. Sendingsmaller packets increases the transmission rate in terms of sent packetsper second, which requires more processing at the clients 1, 1 a, 1 b .. . 1 n and the server 2. It is obvious to a person skilled in the artthat the packets can also be chosen a other sizes e.g. inferior to thenetwork MTU, but the above sizes has shown to be especially efficient.

In FIG. 5 is illustrated how non-priority packets are dropped at thereceiver client in order to avoid delays in a audio or video play queueand to ensure that delays in the packet delivery are not propagated. Instep 501 the server sends a packet to the receiver client, which isreceived in step 502 and in step 503, the receiver client checks thesize of the buffer for non-priority data. If the number of packets inthe buffer is less than 3 the data packet is buffered in step 504. Ifthe buffer is equal to or larger than 3, the packet is dropped in step505. The process of dropping packets at the receiver end does not giveany feedback to the sender and will not influence the sender clientstransfer rate. When TCP congestion happens, packets are sent withsignificant delays compared to the normal interval between e.g. audiosamples of 40 ms. In this case more than one packet can be received atone after a long period of not receiving any packets. If allnon-priority packets are buffered e.g. for playing at a normal rate, thedelay form such events will propagate. This is avoided with a buffer asdescribed at the receiver client and it is obvious that the buffers canhave other sizes and that the buffer size can be adjusted with otherprinciples, just like the buffer management described with respect tothe server.

1-26. (canceled)
 27. Method for transmitting packets of different datatypes from a sender client to a receiver client over a server clientconnection, where a TCP connection for each data type to be transmittedis established between the sender client and the receiver client using aserver, the TCP connection send buffers at the sender client and thereceiver client and at the server are decreased in size or disabled, theNagle algorithm is disabled, a data transfer rate of one or more datatype connections is measured at the server, which transfer rate is sentas feedback information to the sender client, a sending rate at thesender client is adapted based on the feedback information from theserver and the transfer rate measured by the sender client, the datatypes are prioritized in priority data types and delay sensitivenon-priority data types by marking the data packets, non-priority datatype packets are dropped at the sender client if the TCP connectionsdedicated for non-priority data are too busy to send more data, the datatypes are separately buffered at the server, non-priority data typepackets are dropped at the server before they are buffered if acorresponding dedicated data type buffer with a size of N packets isfull until the buffer contains a number of M packets, where M<N, thenon-priority data type packets are dropped at the receiver client if apredetermined buffer with a size of P packets is full.
 28. Methodaccording to claim 27, wherein the non-priority data types comprisesaudio data and/or video data.
 29. Method according to claim 27, whereinthe transfer rate at the server is calculated by measuring the number ofreceived packets in T successive time intervals of duration D and wherepackets dropped by the server is not taken into account when thetransfer rate is calculated.
 30. Method according to claim 27, where thebuffer P has a size of 3 packets.
 31. Method according to claim 27,where the buffer size for non-priority data at the server client is N=4with M=2.
 32. Method according to claim 27, where the transfer rate ofone non-priority data type connection is adapted at the sender client bylimiting the transfer rate of another non-priority data type connectionor a priority data type connection.
 33. Method according to claim 27,where the data type transfer rates at the sender client are adapted bychanging the video or audio sampling rate.
 34. Method according to claim27, where the transfer rate of the data connections is adapted at theconnection level by blocking the connection for specified timeintervals.
 35. System for transmitting packets of different data typesfrom a sender client to a receiver client over a server clientconnection, where a TCP connection for each data type to be transmittedis established between the sender client and the receiver client using aserver, the TCP connection send buffers at the sender client and thereceiver client and at the server are decreased in size or disabled, theNagle algorithm is disabled, a data transfer rate of one or more datatype connections is measured at the server, which transfer rate is sentas feedback information to the sender client, a sending rate at thesender client is adapted based on the feedback information from theserver and the transfer rate measured by the sender client, the datatypes are prioritized in priority data types and delay sensitivenon-priority data types by marking the data packets, non-priority datatype packets are dropped at the sender client if the TCP connectionsdedicated for non-priority data are too busy to send more data, the datatypes are separately buffered at the server, non-priority data typepackets are dropped at the server before they are buffered if acorresponding dedicated data type buffer with a size of N packets isfull until the buffer contains a number of M packets, where M<N, thenon-priority data type packets are dropped at the receiver client if apredetermined buffer with a size of P packets is full.
 36. Systemaccording to claim 35, wherein the non-priority data types comprisesaudio data and/or video data.
 37. System according to claim 35, whereinthe transfer rate at the server is calculated by measuring the number ofreceived packets in T successive time intervals of duration D and wherepackets dropped by the server is not taken into account when thetransfer rate is calculated.
 38. System according to claim 35, where thebuffer P has a size of 3 packets.
 39. System according to claim 35,where the buffer size for non-priority data at the server client is N=4with M=2.
 40. System according to claim 35, where the transfer rate ofone non-priority data type connection is adapted at the sender client bylimiting the transfer rate of another non-priority data type connectionor a priority data type connection.
 41. System according to claim 35,where the data type transfer rates at the sender client are adapted bychanging the video or audio sampling rate.
 42. System according to claim35, where the transfer rate of the data connections is adapted at theconnection level by blocking the connection for specified timeintervals.